Performing computing and data processing functions using a distributed network of computers has become more common as enterprises have increased their reliance on a mobile workforce and have sought ways to reduce the high costs often associated with investments in information technology infrastructure. This has led to the development and deployment of a variety of services and business models, such as web-based services, Software-as-a-Service (SaaS), and cloud-computing based data storage and data processing. Such services and architectures can typically be configured to use varying amounts of computing resources, for example, based on service demand. Some such architectures are “multi-tenant”, that is they provide computing, data processing, and data storage functions to multiple independent users or businesses.
In an effort to permit tenants to access the services and functionality that they desire (which may include providing certain services to their end customers, such as an eCommerce platform), a multi-tenant service platform may permit a tenant to configure certain aspects of the available service(s) to suit their business needs. For example, a business enterprise that uses the service platform may want to provide specific functions or capabilities to their customers. However, customizations introduced into the platform architecture by different tenants may be incompatible with each other in one or more ways, and this can cause a disruption in the services provided to other tenants. For example, such incompatibilities can cause undesirable and/or unintended behavior in the service configurations of multiple tenants, including tenants not associated with the customizations. Certain types of customizations may also impact the operation of the platform in general, such as by altering the manner in which data is accessed or processed.
Conventional approaches to managing potential problems arising from customizations and/or extensions to multi-tenant platform functionality are inefficient, ineffective and/or have undesirable side effects or other drawbacks with respect to at least one significant use case. For example, manually testing system behavior is impractical for anything but the most trivial of extensions. Further, most systems do not support any automatic verification of behavior. Those that do may allow automated verification of extension behavior, but they do not support a way of predicting possible conflicts using extensions declarations.
Embodiments of the invention are directed toward solving these and other problems individually and collectively.